在開始總結行為型設計模式之前先來談談GOF23種設計模式中沒有談到的兩個個行為模式吧。

迭代器模式 Iterator Pattern 和

直譯器模式 Interpreter Pattern

迭代器模式說白了就是透過某個類別去訪問集合中的元素內容，
像是JAVA中的 ArrayList 或是 C#中的 List其實就是這種設計概念，
所以在大多數的開發情況下並不會需要自己使用到這種設計模式。

另外一個直譯器模式(又稱解釋器模式)是一個非常有趣的模式，
它的用途是將 某種狀況轉換成我們希望的答案。
例如我們要解析XML檔案、或是將特定數字轉成日期格式...等。
不過這種行為模式通常都已經有一些早已完善好的套件可以使用，
並不需要我們自行開發。
另一種應用則是我們希望透過直譯器模式來設計一個決策樹，
但這也會引起程式運行效能的問題。

行為型設計模式 總結

行為型設計模式在整個專案中的使用可以說是非常廣泛，
在整個專案中適用的範圍大約佔有七八成。
這也使得在設計的時候常常陷入一種鑽牛角尖的狀態，
導致發生過度設計(over-designed)的狀況發生。
最常與之並論的是缺乏設計(pool-designed)，
這兩個是完全相反的概念。

對設計來說，其實並沒有甚麼絕對的方法能夠分出一套軟體是否過度設計或是缺乏設計。
所以一般來說會透過另外一個層次來協助我們定義是否過度/缺乏設計。
可以透過審視幾個問題來幫我們釐清:

1. 這樣設計有甚麼好處?(列出用途)
2. 這樣設計是否會花更多時間?(與其他方式相比)
3. 這個需求需要這樣設計嗎?(考慮必要性)

我們可以透過前兩點來幫我們釐清是否有設計的必要性，
當有必要性:
有設計: 正常
無設計: 缺乏設計

當無必要性:
有設計: 過度設計
無設計: 正常

結語

對於設計模式的使用與否及其必要性，我們不需要特別嚴格的規範。
在除了在不同開發階段需求與時間的掌握都有所考量外，
不同的開發人員對於設計必要性的定義也會有所不同。

最後，專案中過度設計及缺乏設計的程式碼，在開發過程會不斷地出現，
當發生問題時，每種專案管理都會有不同的方式，協助開發人員不斷的Review及修正。